تحلیلی جامع از عملکرد Shadow DOM در وب کامپوننت‌ها، با تمرکز بر تأثیر ایزوله‌سازی استایل بر رندرینگ مرورگر، هزینه‌های محاسبه استایل و سرعت کلی برنامه.
عملکرد Shadow DOM در وب کامپوننت‌ها: نگاهی عمیق به تأثیر ایزوله‌سازی استایل
وب کامپوننت‌ها (Web Components) نویدبخش انقلابی در توسعه فرانت‌اند هستند: کپسوله‌سازی واقعی. توانایی ساخت عناصر رابط کاربری مستقل و قابل استفاده مجدد که در هنگام قرار گرفتن در یک محیط جدید دچار مشکل نشوند، هدف نهایی برای برنامه‌های کاربردی در مقیاس بزرگ و سیستم‌های طراحی (design systems) است. در قلب این کپسوله‌سازی، Shadow DOM قرار دارد؛ فناوری‌ای که درخت‌های DOM محدود شده و مهم‌تر از آن، CSS ایزوله‌شده را فراهم می‌کند. این ایزوله‌سازی استایل یک پیروزی بزرگ برای قابلیت نگهداری (maintainability) است و از نشت استایل (style leaks) و تداخل نام‌گذاری که دهه‌هاست توسعه CSS را با مشکل مواجه کرده، جلوگیری می‌کند.
اما این ویژگی قدرتمند یک سؤال اساسی را برای توسعه‌دهندگان آگاه به عملکرد مطرح می‌کند: هزینه عملکردی ایزوله‌سازی استایل چقدر است؟ آیا این کپسوله‌سازی یک مزیت «رایگان» است، یا سرباری را به همراه دارد که باید آن را مدیریت کنیم؟ پاسخ، همانطور که اغلب در مورد عملکرد وب صادق است، پیچیده و ظریف است. این موضوع شامل بده‌بستان‌هایی بین هزینه راه‌اندازی اولیه، مصرف حافظه، و مزایای فوق‌العاده محاسبه مجدد استایل محدود شده (scoped style recalculation) در زمان اجرا (runtime) است.
این بررسی عمیق، پیامدهای عملکردی ایزوله‌سازی استایل در Shadow DOM را کالبدشکافی خواهد کرد. ما بررسی خواهیم کرد که مرورگرها چگونه استایل‌دهی را مدیریت می‌کنند، دامنه سراسری (global scope) سنتی را با دامنه کپسوله‌شده Shadow DOM مقایسه می‌کنیم و سناریوهایی را تحلیل می‌کنیم که در آن‌ها Shadow DOM یک افزایش عملکرد قابل توجه ایجاد می‌کند در مقابل سناریوهایی که ممکن است سربار ایجاد کند. در پایان، شما یک چارچوب روشن برای تصمیم‌گیری آگاهانه در مورد استفاده از Shadow DOM در برنامه‌های کاربردی حساس به عملکرد خود خواهید داشت.
درک مفهوم اصلی: Shadow DOM و کپسوله‌سازی استایل
قبل از اینکه بتوانیم عملکرد آن را تحلیل کنیم، باید درک دقیقی از چیستی Shadow DOM و چگونگی دستیابی آن به ایزوله‌سازی استایل داشته باشیم.
Shadow DOM چیست؟
Shadow DOM را به عنوان یک «DOM درون یک DOM» در نظر بگیرید. این یک درخت DOM پنهان و کپسوله‌شده است که به یک عنصر DOM معمولی، به نام میزبان سایه (shadow host)، متصل می‌شود. این درخت جدید با یک ریشه سایه (shadow root) شروع می‌شود و به طور جداگانه از DOM اصلی سند رندر می‌شود. خط بین DOM اصلی (که اغلب Light DOM نامیده می‌شود) و Shadow DOM به عنوان مرز سایه (shadow boundary) شناخته می‌شود.
این مرز بسیار حیاتی است. این مرز به عنوان یک مانع عمل می‌کند و نحوه تعامل دنیای خارج با ساختار داخلی کامپوننت را کنترل می‌کند. برای بحث ما، مهم‌ترین عملکرد آن، ایزوله‌سازی CSS است.
قدرت ایزوله‌سازی استایل
ایزوله‌سازی استایل در Shadow DOM دو معنا دارد:
- استایل‌های تعریف‌شده در داخل یک shadow root به بیرون نشت نمی‌کنند و بر عناصر موجود در Light DOM تأثیر نمی‌گذارند. شما می‌توانید از انتخابگرهای ساده‌ای مانند
h3یا.titleدر داخل کامپوننت خود استفاده کنید بدون اینکه نگران تداخل آن‌ها با سایر عناصر صفحه باشید. - استایل‌های Light DOM (CSS سراسری) به داخل shadow root نشت نمی‌کنند. یک قانون سراسری مانند
p { color: blue; }بر تگ‌های<p>داخل درخت سایه کامپوننت شما تأثیر نخواهد گذاشت.
این امر نیاز به قراردادهای نام‌گذاری پیچیده مانند BEM (Block, Element, Modifier) یا راه‌حل‌های CSS-in-JS که نام‌های کلاس منحصربه‌فرد تولید می‌کنند را از بین می‌برد. مرورگر محدوده‌بندی (scoping) را به صورت بومی برای شما انجام می‌دهد. این منجر به کامپوننت‌های تمیزتر، قابل پیش‌بینی‌تر و بسیار قابل حمل‌تر می‌شود.
این مثال ساده را در نظر بگیرید:
استایل‌شیت سراسری (Light DOM):
<style>
p { color: red; font-family: sans-serif; }
</style>
بدنه HTML:
<p>This is a paragraph in the Light DOM.</p>
<my-component></my-component>
جاوااسکریپت وب کامپوننت:
class MyComponent extends HTMLElement {
constructor() {
super();
const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.innerHTML = `
<style>
p { color: green; font-family: monospace; }
</style>
<p>This is a paragraph inside the Shadow DOM.</p>
`;
}
}
customElements.define('my-component', MyComponent);
در این سناریو، پاراگراف اول قرمز و با فونت sans-serif خواهد بود. پاراگراف داخل <my-component> سبز و با فونت monospace خواهد بود. هیچ یک از قوانین استایل با دیگری تداخل ندارد. این جادوی ایزوله‌سازی استایل است.
سؤال عملکرد: ایزوله‌سازی استایل چگونه بر مرورگر تأثیر می‌گذارد؟
برای درک تأثیر عملکرد، باید نگاهی به زیربنای نحوه رندر کردن یک صفحه توسط مرورگرها بیندازیم. به طور خاص، باید بر روی مرحله «محاسبه استایل» (Style Calculation) در مسیر رندرینگ حیاتی (critical rendering path) تمرکز کنیم.
سفری در پایپ‌لاین رندرینگ مرورگر
به زبان ساده، وقتی یک مرورگر صفحه‌ای را رندر می‌کند، چندین مرحله را طی می‌کند:
- ساخت DOM: HTML به مدل شیء سند (Document Object Model یا DOM) تجزیه می‌شود.
- ساخت CSSOM: کدهای CSS به مدل شیء CSS (CSS Object Model یا CSSOM) تجزیه می‌شوند.
- درخت رندر (Render Tree): DOM و CSSOM در یک درخت رندر ترکیب می‌شوند که فقط شامل گره‌های (nodes) مورد نیاز برای رندرینگ است.
- چیدمان (Layout یا Reflow): مرورگر اندازه و موقعیت دقیق هر گره را در درخت رندر محاسبه می‌کند.
- نقاشی (Paint): مرورگر پیکسل‌های هر گره را بر روی لایه‌ها پر می‌کند.
- ترکیب (Composite): لایه‌ها به ترتیب صحیح روی صفحه نمایش داده می‌شوند.
فرآیند ترکیب DOM و CSSOM اغلب محاسبه استایل (Style Calculation) یا Recalculate Style نامیده می‌شود. اینجاست که مرورگر انتخابگرهای CSS را با عناصر DOM تطبیق می‌دهد تا استایل‌های نهایی محاسبه‌شده آن‌ها را تعیین کند. این مرحله تمرکز اصلی تحلیل عملکرد ماست.
محاسبه استایل در Light DOM (روش سنتی)
در یک برنامه سنتی بدون Shadow DOM، تمام CSS در یک دامنه سراسری و واحد قرار دارد. هنگامی که مرورگر نیاز به محاسبه استایل‌ها دارد، باید هر قانون استایل را در برابر تقریباً هر عنصر DOM در نظر بگیرد.
پیامدهای عملکردی آن قابل توجه است:
- دامنه بزرگ: در یک صفحه پیچیده، مرورگر باید با یک درخت عظیم از عناصر و مجموعه بزرگی از قوانین کار کند.
- پیچیدگی انتخابگر: انتخابگرهای پیچیده‌ای مانند
.main-nav > li:nth-child(2n) .sub-menu a:hoverمرورگر را مجبور به کار بیشتری برای تعیین اینکه آیا یک قانون با یک عنصر مطابقت دارد یا نه، می‌کنند. - هزینه بالای ابطال (Invalidation): هنگامی که شما یک کلاس را روی یک عنصر تغییر می‌دهید (مثلاً از طریق جاوااسکریپت)، مرورگر همیشه از تأثیر کامل آن آگاه نیست. ممکن است مجبور شود استایل‌های بخش بزرگی از درخت DOM را مجدداً ارزیابی کند تا ببیند آیا این تغییر بر عناصر دیگر تأثیر می‌گذارد یا خیر. به عنوان مثال، تغییر یک کلاس در عنصر `` به طور بالقوه می‌تواند بر تمام عناصر دیگر صفحه تأثیر بگذارد.
محاسبه استایل با Shadow DOM (روش کپسوله‌شده)
Shadow DOM این دینامیک را اساساً تغییر می‌دهد. با ایجاد دامنه‌های استایل ایزوله‌شده، دامنه سراسری یکپارچه را به تعداد زیادی دامنه کوچک‌تر و قابل مدیریت تقسیم می‌کند.
در اینجا نحوه تأثیر آن بر عملکرد آمده است:
- محاسبه محدود شده: هنگامی که تغییری در داخل shadow root یک کامپوننت رخ می‌دهد (مثلاً یک کلاس اضافه می‌شود)، مرورگر با اطمینان می‌داند که تغییرات استایل به همان shadow root محدود است. تنها کافی است محاسبه مجدد استایل را برای گره‌های *درون آن کامپوننت* انجام دهد.
- کاهش ابطال: موتور استایل نیازی به بررسی این ندارد که آیا تغییری در کامپوننت A بر کامپوننت B یا هر بخش دیگری از Light DOM تأثیر می‌گذارد یا خیر. دامنه ابطال به شدت کاهش می‌یابد. این مهم‌ترین مزیت عملکردی ایزوله‌سازی استایل در Shadow DOM است.
یک کامپوننت گرید داده (data grid) پیچیده را تصور کنید. در یک ساختار سنتی، به‌روزرسانی یک سلول ممکن است باعث شود مرورگر استایل‌ها را برای کل گرید یا حتی کل صفحه دوباره بررسی کند. با Shadow DOM، اگر هر سلول وب کامپوننت خودش باشد، به‌روزرسانی استایل یک سلول تنها یک محاسبه مجدد استایل کوچک و محلی را در محدوده همان سلول فعال می‌کند.
تحلیل عملکرد: بده‌بستان‌ها و ظرافت‌ها
مزیت محاسبه مجدد استایل محدود شده واضح است، اما این تمام ماجرا نیست. ما باید هزینه‌های مرتبط با ایجاد و مدیریت این دامنه‌های ایزوله‌شده را نیز در نظر بگیریم.
مزیت: محاسبه مجدد استایل محدود شده
اینجاست که Shadow DOM می‌درخشد. افزایش عملکرد بیشتر در برنامه‌های پویا و پیچیده مشهود است.
- برنامه‌های پویا: در برنامه‌های تک‌صفحه‌ای (SPAs) که با فریمورک‌هایی مانند Angular، React یا Vue ساخته شده‌اند، رابط کاربری دائماً در حال تغییر است. کامپوننت‌ها اضافه، حذف و به‌روزرسانی می‌شوند. Shadow DOM تضمین می‌کند که این تغییرات مکرر به طور کارآمد مدیریت شوند، زیرا هر به‌روزرسانی کامپوننت تنها یک محاسبه مجدد استایل کوچک و محلی را فعال می‌کند. این منجر به انیمیشن‌های روان‌تر و تجربه کاربری واکنش‌گراتر می‌شود.
- کتابخانه‌های کامپوننت در مقیاس بزرگ: برای یک سیستم طراحی با صدها کامپوننت که در یک سازمان بزرگ استفاده می‌شود، Shadow DOM یک نجات‌دهنده عملکرد است. این مانع از آن می‌شود که CSS کامپوننت‌های یک تیم، طوفان‌های محاسبه مجدد استایل ایجاد کند که بر کامپوننت‌های تیم دیگر تأثیر بگذارد. عملکرد کلی برنامه قابل پیش‌بینی‌تر و مقیاس‌پذیرتر می‌شود.
نقطه ضعف: تجزیه اولیه و سربار حافظه
در حالی که به‌روزرسانی‌های زمان اجرا سریع‌تر هستند، استفاده از Shadow DOM یک هزینه اولیه دارد.
- هزینه راه‌اندازی اولیه: ایجاد یک shadow root یک عملیات بدون هزینه نیست. برای هر نمونه از کامپوننت، مرورگر باید یک shadow root جدید ایجاد کند، استایل‌های درون آن را تجزیه کند و یک CSSOM جداگانه برای آن دامنه بسازد. برای صفحه‌ای با تعداد انگشت‌شماری کامپوننت پیچیده، این هزینه ناچیز است. اما برای صفحه‌ای با هزاران کامپوننت ساده، این راه‌اندازی اولیه می‌تواند قابل توجه باشد.
- استایل‌های تکراری و ردپای حافظه: این مورد بیشترین نگرانی عملکردی است که ذکر می‌شود. اگر شما 1000 نمونه از کامپوننت
<custom-button>در یک صفحه داشته باشید و هر کدام استایل‌های خود را از طریق تگ<style>در shadow root خود تعریف کنند، شما در عمل همان قوانین CSS را 1000 بار در حافظه تجزیه و ذخیره می‌کنید. هر shadow root نمونه CSSOM خود را دریافت می‌کند. این می‌تواند منجر به ردپای حافظه بسیار بزرگ‌تری در مقایسه با یک استایل‌شیت سراسری واحد شود.
عامل «بستگی دارد»: چه زمانی واقعاً اهمیت دارد؟
بده‌بستان عملکردی به شدت به مورد استفاده شما بستگی دارد:
- کامپوننت‌های کم اما پیچیده: برای کامپوننت‌هایی مانند یک ویرایشگر متن غنی، یک پخش‌کننده ویدیو، یا یک مصورسازی داده تعاملی، Shadow DOM تقریباً همیشه یک برد خالص عملکردی است. این کامپوننت‌ها حالت‌های داخلی پیچیده و به‌روزرسانی‌های مکرر دارند. مزیت عظیم محاسبه مجدد استایل محدود شده در طول تعامل کاربر، بسیار بیشتر از هزینه راه‌اندازی یک‌باره است.
- کامپوننت‌های زیاد اما ساده: اینجاست که بده‌بستان ظریف‌تر است. اگر لیستی با 10,000 آیتم ساده (مثلاً یک کامپوننت آیکون) رندر کنید، سربار حافظه ناشی از 10,000 استایل‌شیت تکراری می‌تواند به یک مشکل واقعی تبدیل شود و به طور بالقوه رندر اولیه را کند کند. این دقیقاً همان مشکلی است که راه‌حل‌های مدرن برای رفع آن طراحی شده‌اند.
بنچمارکینگ عملی و راه‌حل‌های مدرن
تئوری مفید است، اما اندازه‌گیری در دنیای واقعی ضروری است. خوشبختانه، ابزارهای مدرن مرورگر و ویژگی‌های جدید پلتفرم به ما این امکان را می‌دهند که هم تأثیر را اندازه‌گیری کنیم و هم نقاط ضعف را کاهش دهیم.
چگونه عملکرد استایل را اندازه‌گیری کنیم
بهترین دوست شما در اینجا تب Performance در ابزارهای توسعه‌دهنده مرورگر شماست (مانند Chrome DevTools).
- یک پروفایل عملکرد را هنگام تعامل با برنامه خود ضبط کنید (مثلاً با بردن ماوس روی عناصر، افزودن آیتم‌ها به لیست).
- به دنبال نوارهای بنفش طولانی در نمودار شعله‌ای (flame chart) با برچسب "Recalculate Style" بگردید.
- روی یکی از این رویدادها کلیک کنید. تب خلاصه به شما خواهد گفت که چقدر طول کشیده، چه تعداد عنصر تحت تأثیر قرار گرفته‌اند و چه چیزی باعث محاسبه مجدد شده است.
با ایجاد دو نسخه از یک کامپوننت—یکی با Shadow DOM و دیگری بدون آن—می‌توانید تعاملات مشابهی را اجرا کرده و مدت زمان و دامنه رویدادهای "Recalculate Style" را مقایسه کنید. در سناریوهای پویا، شما اغلب خواهید دید که نسخه Shadow DOM تعداد زیادی محاسبات استایل کوچک و سریع تولید می‌کند، در حالی که نسخه Light DOM محاسبات کمتر اما با زمان اجرای بسیار طولانی‌تری تولید می‌کند.
تغییردهنده بازی: استایل‌شیت‌های قابل ساخت (Constructable Stylesheets)
مشکل استایل‌های تکراری و سربار حافظه یک راه‌حل مدرن و قدرتمند دارد: Constructable Stylesheets. این API به شما اجازه می‌دهد تا یک شیء `CSSStyleSheet` را در جاوااسکریپت ایجاد کنید، که سپس می‌تواند بین چندین shadow root به اشتراک گذاشته شود.
به جای اینکه هر کامپوننت تگ <style> خود را داشته باشد، شما استایل‌ها را یک بار تعریف کرده و آن‌ها را در همه جا اعمال می‌کنید.
مثالی از استفاده از Constructable Stylesheets:
// 1. Create the stylesheet object ONCE
const sheet = new CSSStyleSheet();
sheet.replaceSync(`
:host { display: inline-block; }
button { background-color: blue; color: white; border: none; padding: 10px; }
`);
// 2. Define the component
class SharedStyleButton extends HTMLElement {
constructor() {
super();
const shadowRoot = this.attachShadow({ mode: 'open' });
// 3. Apply the SHARED stylesheet to this instance
shadowRoot.adoptedStyleSheets = [sheet];
shadowRoot.innerHTML = `<button>Click Me</button>`;
}
}
customElements.define('shared-style-button', SharedStyleButton);
اکنون، اگر 1000 نمونه از <shared-style-button> داشته باشید، تمام 1000 shadow root به دقیقاً همان شیء استایل‌شیت در حافظه ارجاع خواهند داد. CSS فقط یک بار تجزیه می‌شود. این به شما بهترین‌های هر دو جهان را می‌دهد: مزیت عملکرد زمان اجرا از محاسبه مجدد استایل محدود شده، بدون هزینه حافظه و زمان تجزیه استایل‌های تکراری. این رویکرد پیشنهادی برای هر کامپوننتی است که ممکن است بارها در یک صفحه نمونه‌سازی شود.
Shadow DOM اعلانی (DSD)
پیشرفت مهم دیگر، Shadow DOM اعلانی (Declarative Shadow DOM) است. این به شما امکان می‌دهد تا یک shadow root را مستقیماً در HTML رندر شده در سرور خود تعریف کنید. مزیت اصلی عملکردی آن برای بارگذاری اولیه صفحه است. بدون DSD، یک صفحه رندر شده در سرور با وب کامپوننت‌ها باید منتظر اجرای جاوااسکریپت بماند تا تمام shadow rootها را متصل کند، که می‌تواند باعث یک فلش محتوای بدون استایل (FOUC) یا تغییر چیدمان (layout shift) شود. با DSD، مرورگر می‌تواند کامپوننت، از جمله Shadow DOM آن را، مستقیماً از جریان HTML تجزیه و رندر کند، و معیارهایی مانند First Contentful Paint (FCP) و Largest Contentful Paint (LCP) را بهبود بخشد.
بینش‌های عملی و بهترین شیوه‌ها
خب، چگونه این دانش را به کار ببریم؟ در اینجا چند راهنمای عملی آورده شده است.
چه زمانی از Shadow DOM برای عملکرد استفاده کنیم
- کامپوننت‌های قابل استفاده مجدد: برای هر کامپوننتی که برای یک کتابخانه یا سیستم طراحی در نظر گرفته شده است، قابلیت پیش‌بینی و محدوده‌بندی استایل Shadow DOM یک برد معماری و عملکردی بزرگ است.
- ویجت‌های پیچیده و مستقل: اگر در حال ساخت یک کامپوننت با منطق و حالت داخلی زیاد هستید، مانند یک انتخابگر تاریخ یا یک نمودار تعاملی، Shadow DOM عملکرد آن را از بقیه برنامه محافظت می‌کند.
- برنامه‌های پویا: در SPAها که DOM دائماً در حال تغییر است، محاسبات مجدد محدود شده Shadow DOM رابط کاربری را سریع و واکنش‌گرا نگه می‌دارد.
چه زمانی باید محتاط بود
- سایت‌های بسیار ساده و استاتیک: اگر در حال ساخت یک سایت محتوای ساده هستید، سربار Shadow DOM ممکن است غیرضروری باشد. یک استایل‌شیت سراسری با ساختار خوب اغلب کافی و ساده‌تر است.
- پشتیبانی از مرورگرهای قدیمی: اگر نیاز به پشتیبانی از مرورگرهای قدیمی‌تری دارید که از وب کامپوننت‌ها یا Constructable Stylesheets پشتیبانی نمی‌کنند، بسیاری از مزایا را از دست خواهید داد و ممکن است به polyfillهای سنگین‌تری تکیه کنید.
توصیه‌های گردش کار مدرن
- به طور پیش‌فرض از Constructable Stylesheets استفاده کنید: برای هر توسعه کامپوننت جدید، از Constructable Stylesheets استفاده کنید. آن‌ها عیب اصلی عملکردی Shadow DOM را حل می‌کنند و باید انتخاب پیش‌فرض شما باشند.
- از ویژگی‌های سفارشی CSS برای تم‌دهی استفاده کنید: برای اینکه به کاربران اجازه دهید کامپوننت‌های شما را سفارشی کنند، از ویژگی‌های سفارشی CSS (`--my-color: blue;`) استفاده کنید. آن‌ها یک روش استاندارد W3C برای نفوذ به مرز سایه به روشی کنترل‌شده هستند و یک API تمیز برای تم‌دهی ارائه می‌دهند.
- از `::part` و `::slotted` بهره ببرید: برای کنترل دقیق‌تر استایل‌دهی از بیرون، عناصر خاص را با استفاده از ویژگی `part` در معرض دید قرار دهید و آن‌ها را با شبه‌عنصر `::part()` استایل‌دهی کنید. از `::slotted()` برای استایل‌دهی به محتوایی که از Light DOM به کامپوننت شما منتقل می‌شود، استفاده کنید.
- پروفایل بگیرید، فرض نکنید: قبل از شروع یک تلاش بزرگ برای بهینه‌سازی، از ابزارهای توسعه‌دهنده مرورگر استفاده کنید تا تأیید کنید که محاسبه استایل واقعاً یک گلوگاه در برنامه شماست. بهینه‌سازی زودهنگام ریشه بسیاری از مشکلات است.
نتیجه‌گیری: دیدگاهی متعادل در مورد عملکرد
ایزوله‌سازی استایل ارائه شده توسط Shadow DOM نه یک راه‌حل جادویی برای عملکرد است و نه یک ابزار پرهزینه. این یک ویژگی معماری قدرتمند با مشخصات عملکردی واضح است. مزیت اصلی عملکردی آن—محاسبه مجدد استایل محدود شده—یک تغییردهنده بازی برای برنامه‌های وب مدرن و پویا است که منجر به به‌روزرسانی‌های سریع‌تر و یک رابط کاربری مقاوم‌تر می‌شود.
نگرانی تاریخی در مورد عملکرد—سربار حافظه ناشی از استایل‌های تکراری—تا حد زیادی با معرفی Constructable Stylesheets برطرف شده است، که ترکیب ایده‌آلی از ایزوله‌سازی استایل و بهره‌وری حافظه را فراهم می‌کنند.
با درک فرآیند رندرینگ مرورگر و بده‌بستان‌های موجود، توسعه‌دهندگان می‌توانند از Shadow DOM برای ساخت برنامه‌هایی استفاده کنند که نه تنها قابل نگهداری‌تر و مقیاس‌پذیرتر هستند، بلکه عملکرد بالایی نیز دارند. کلید موفقیت، استفاده از ابزارهای مناسب برای کار، اندازه‌گیری تأثیر و ساخت با درک مدرن از قابلیت‌های پلتفرم وب است.